Update CFS and other OneBranch tooling#1422
Update CFS and other OneBranch tooling#1422andyleejordan wants to merge 10 commits intoPowerShell:mainfrom
Conversation
The crux of our problems was the cross-org feed permissions.
The version ms-stable stopped being supported in 2024 so we've been on an old toolchain.
Which removes the need to do complicated authentication.
|
Watching the OneBranch run, it failed on Windows only at the signing step due to the internal service timing out, so I think this is at least good to go for review. Edit: found the reason for that, and for the previously added |
The OneBranch template automatically checks out the repo, doing it again is what messed up CodeQL and signing.
|
Last thing is symbols and uh, fixing the path highlighted that this wasn't working in the first place. Went back and looked at a "successful" build... Linux
macOS -- N/A Windows
|
It never worked on Linux in the first place, so disable that. On Windows it needs to be where we built, not where we're packaging the MSIX (and so have lost our sources and symbols).
|
Assigning reviewers now as that's a green build. I still don't think the Windows symbols are source mapped but that's a different investigation. |
|
By the way this is a follow-up to #1410 as I needed the OneBranch pipeline to work again so I could get the MSIX, RPM, and DEB packages and verify them. |
|
Nope, one more thing to fix. MSIX bundle is getting created under |
We were assuming this was bin root (like in the old package script).
|
Bingo, MSIX bundle now exists too. |
1 participant
In the course of debugging why we couldn't so much as
cargo install tree-sitter-cliI discovered a number of issues resolved in this PR.For the
msrustuptoolchain,ms-stablestopped being supported in 2024, meaning under the covers we've just been usingms-prod-1.88. I've updated the OneBranch pipelines to specifically usems-prod-1.93. The OneBranch documentation recommends a specific pin, and not e.g.ms-prod. They also recommend using arust-toolchain.tomlfile, but that gets a bit in the way of our existing logic which detects and usesmsrustuponly when available.I've switched us from the mscodehub CFS feed to a new dedicated
DSCCargoMirrorCFS feed in msazure. By not being cross-org, we don't have to deal with complicated authentication with a service connection, and can just rely on theCargoAuthenticatetask. I know of no compelling reason to stick to the mscodehub feed when we can eliminate a lot of headache here.If and when as a dev you cannot update the feed, there is a very hidden button titled "Allow externally-sourced versions" available only after going to the feed and searching the upstream sources for a package. I've found it sometimes just gets turned off, which then prevents us from adding packages to the feed, and this will appear as an authentication failure. Authenticating locally with either
artifacts-cargo-credproviderormsrustupdoes indeed work, but that setting must be toggled on.I removed
ob_restore_phase: trueas that was an old workaround for accessing network resources that were not allow-listed, and it messed up the timing of the tasks. Seems like it was put there because we were errantly adding a secondcheckout: selftask (it's an additional since the OneBranch template already does that). With that gone, ordering is fine and signing and CodeQL is happy.We also weren't passing through
-UseX64MakeAppxwhen we migrated the MSIX build function, and that needs to happen for one of the OneBranch builds.